Two further suggestions that might make sense still here:

1. In the error for fetch() to explicitly call out that Fastly accepts a backend parameter, so making the error message more specific to this case.
2. Changing the imported function on fastly:backend to import { enforceExplicitBackends } from 'fastly:backend' or similar, to more clearly demonstrate this is now a security feature that can be used.

I've added the suggestion here in renaming to enforceExplicitBackends with an optional default backend argument, and updating the error messages and types.

I especially like being able to set the implicit backend for any fetch() call via enforceExplicitBackends(), as this gives a bit more control over your third party dependencies.

Given the security and configuration benefits of using static backends, and the fact that you can't see on the manage UI whether dynamic backends are enabled for a service, I'm a bit conflicted over whether to enable them by default. Our team began using dynamic backends, but has since switched our JS code to exclusively use static backends — despite this, IIRC, dynamic backends were left enabled on the services. This is a good reminder for us to fix that, but, for customers in our situation, this probably represents a breaking change worth noting.

I had an idea while reviewing this; what if:

• by default, dynamic backends will be allowed only if you pass a special flag to fetch, roughly something like fetch("http://fastly.com", { dynamicBackend: true }). This would let you use them intentionally in your own code, while providing some safety from third party dependencies.
• You could then call a function like setImplicitBackend({ backend: ... }), useful for any third party libraries making fetch() calls, or just to reduce boilerplate wherever the compute service calls fetch()
• Or globally allow implicit dynamic backends like setImplicitBackend({ dynamicBackend: true }), to opt out of any protection

This would still let you use dynamic backends without enabling them twice, and provide some safety/control of third party dependencies, with the ability to opt out for convenience. But obviously it's a larger breaking change.

Thanks for the thoughtful points here, it's really appreciated in trying to consider what API is best for users. I think the benefit of dynamic backends is that they allow code to run without modification from other providers, which may be useful for new users.

It is perfectly valid though for us to conclude here that allowDynamicBackends(true) remains the recommended process, this PR was just about investigating if we want to prioritise support standards-compatibility in the name of being user friendly, versus security.

But since the security is already handled on the service-level, flipping the default seemed like it didn't have to tradeoff between both.

On the other hand, as you say, being able to set the default implicit backend may be enough in many cases too.

I'm not going to rush landing this as I think it requires some careful though, but hopefully we can work towards the right user experience going forward.

Putting some more thought here - the Go SDK doesn't have a separate runtime-level flag itself, and neither does the Rust SDK, therefor I would like to move ahead with landing this.

This PR is now ready to merge, I will land and release on Monday unless there is any further feedback.